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(54) User controlled browser 

(57) A mechanism provides a user-controlled infor- 
mation disclosure process. A user information database 
(206.208). a BrowserlD Client applet (406), and a 
BrowserlD Website database (408) are configured at a 
user terminal (102). The user information database con- 
tains a plurality of information records about a user's 
identification information and access levels for the 
respective information records. The BrowserlD Website 
database contains the names of web sites and access 
levels for the respective web sites. In response to a 
request for user information from a web site, the 
BrowserlD Client applet checks the existing access 
level in the BrowserlD Website database for the web 
site (or negotiates a new level), and if appropriate, 
retrieves the access key granted by the web site to gain 
access to a controlled portion of a website. 
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Description 

The present invention relates to a method and 
apparatus for providing user identification and transac- 
tion information to web sites in the process of getting 
access to the web sites. 

It is known a user can retrieve information from 
world wide web sites (or web sites) via the Internet. 
More specifically, in retrieving desired information from 
a particular web site, the user sends a service request 
to the web site by using the web browser software at a 
user terminal. Upon receiving the service request, 
server software for the web site searches the informa- 
tion repository (organized as web pages) in the web site 
according to the request, and sends the desired infor- 
mation to the user terminal. Upon receiving the desired 
information, the web browser software displays the 
desired information in page format to the user. 

To enhance the quality of, expand the market for, 
and provide new services for their web site services, 
many web sites require visitor identification and ask for 
personal identification and demographic information 
before processing received service requests. Further, 
the user may be required to provide a credit card or 
other sensitive financial information The user identifica- 
tion can be useful for a number of purposes: to authen- 
ticate web visitors, to selectively grant access 
privileges, to facilitate the administration and billing of 
marketable services over the Internet, to provide more 
focused responses, to build customer history database 
to facilitate the consequent repeating services, to collect 
marketing information, etc. 

At the present time, several approaches have been 
developed to gather user identification information. One 
approach, used by Netscape Inc., is to "quietly" main- 
tain a file within the client accessible to the browser soft- 
ware at user terminals. When a user terminal sends a 
service request to a web site, the browser software first 
provides to the server software the information within 
the file (known as "cookies.txt") that applies to the 
server's domain (Internet address). One problem with 
this approach is that users have little control (short of 
deleting the file or its entries), regardless of what types 
of web sites they are visiting. Another problem with this 
approach is that the user identification may be incom- 
plete, because the user identification gathered is limited 
to the hardware and software configuration at the user 
terminal. Current tracking facilities identify a web visitor 
by recognizing a unique identifier associated with the 
web visitor based on exchanges between the browser 
software and the server software. Usually, the identifier 
is the IP (Internet Protocol) address of the user terminal 
the visitor is using. This type of identification is problem- 
atic since many on-line service providers (such as 
American Online and CompuServe) assign an IP 
address per user session and will re-use the IP address 
for other users when it is released. It is also possible 
that corporate proxy servers hide (or mask) individual IP 
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addresses for associated user terminals with their fire- 
walls. 

In another approach, many web sites have imple- 
mented a registration facility. After sending a service 

5 request to a web site, an HTML (Hyper Text Markup 
Language) form is presented to the web visiter, request- 
ing the visitor to fill in the form to provide information 
such as name, e-mail address, phone number, business 
affiliation, etc. Often the registration is accompanied by 

10 the issuance of personal ID and password for use in the 
next visit to the web site, typically giving the visitor 
access to pages of information and services not other- 
wise available. Such a registration process is cumber- 
some and inconvenient for a web site user. The format 

is of the identification information is designed to satisfy 
each individual web site and may be not consistent to 
the user. It is quite possible the information being 
requested is not handy at the moment when the user is 
visiting a web site, ff multiple personal IDs and pass 

20 words are issued, it is difficult for the user to remember 
the IDs and passwords and match them with appropri- 
ate web sites. 

To strike a balance between the users* privacy and 
the necessity to have user identification information, 

25 Daniel W. Connolly made two proposals in July of 1995 
("Request-ID header field* and "Anonymous Authenti- 
cation"). These two proposals focus on per session 
tracking and thus are not amenable to establishing a 
long term relationship between a web side provider and 

30 customer, or to providing insight to users identification 
for demographic purposes. A third proposal by Daniel 
W. Connolly suggests establishing an "electronic busi- 
ness card" through the use of HTML forms and ID field 
names that would facilitate the filling in of common reg- 

35 istration forms by having standardized field names that 
could automatically be f fled by a browser. The browser 
user would have the opportunity not to submit the infor- 
mation or to edit it prior to submitting it. A problem with 
this proposal is the negative impact that ft would have 

40 on caching performed by proxy servers since the ID 
information would be transmitted via URLs (Uniform 
Resource Locators) that are the keys to cached web 
pages. 

Therefore, there exists a need to provide a method 
45 and apparatus that can provide user identification infor- 
mation to web sites under users' control. 

There exists another need to provide a method and 
apparatus that can provide user identification informa- 
tion to web sites with control, consistency, efficiency, 
so and convenience to the users. 

The object o1 the present invention is to meet these 
needs. 

According to the invention a method for providing 
information to a web site at a user terminal, character- 
55 ized by the steps of: 

at the user terminal. 
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(a) establishing a plurality of information 
records with respective access level indicators 
for indicating access levels; 

(b) receiving a request from the web site with 
an access leve! being associated with the web 
site; 

(c) checking the access level for the web site; 

and 

(d) retrieving information records based on said 
access level indicators associated with the 
information records and the access level asso- 
ciated with the web site. 

Also according to the invention an apparatus for 
providing information to a web site at a user terminal, 
characterized by the user terminal comprising 

a receiver circuit for receiving a request from the 
web site with an access level being associated with 
the web site; and 

a processor logic for checking the access level for 
the web site; and for retrieving information based on 
the access level associated with the web site. 

The invention will be described by way of example 
with reference to the appended drawings, in which: 

Figure 1 shows an exemplary data network config- 
uration; 

Figure 2 shows a hardware block diagram of a rep- 
resentative one of the user terminals of Figure 1 ; 
Figure 3 shows a hardware block diagram for a 
computer system, which is able to support any one . 
of the web sites cf Figure 1 ; 
Figure 4 shows a software block diagram for a rep- 
resentative one of the user terminals, and for a rep- 
resentative one of the web sites, shown in Figure 1 ; 
Figure 5 shows Browser ID database of Figure 4 in 
greater detail; 

Figure 6 shows BrowserlD website database of Fig- 
ure 4 in greater detail: and 

Figure 7 shows a flowchart illustrating the steps of 
disclo Wig user information to a web site. 

Referring to Figure 1 , there is shown an exemplary 
data netwc k confir i nation 100, which includes a plural- 
ity of user terminals 'J02.-,, 102. 2 , 102. M ), a plurality 
of web siUs (112.!, 112. 2 1 12-n). ancl a data net- 
work 106. Tach of the user terminals can get access to 
the web sites via data network 106. 

As shown in Figure 2, a user terminal 200 com- 
prises a processing unit 202, a memory device 204, a 
disk drive interface 203, a display interface 212, a serial 
interface £24, and a network communication interface 
234, ail connected to a system bus 214. 

A hard disk 206 is coupled to the disk drive inter- 
face 208; r display monitor 210 is coupled to the display 
interface r 2; and a mouse 225 and a keyboard 226 are 



cSupled to the serial interface 224. 

Memory device 204 and the hard disk 206 are both 
able to store programs. However, memory device 204 
has fester access speed than hard disk 206. while hard 

5 disk 206 has higher capacity than memory device 204. 
Network communication interface 234 is able to 
provide an interface between the user terminal and data 
network 106. More specifically, all software function 
blocks as shown in f igures 2 and 3 get access to data 

w network 106 via network communication interface 234 
in compliance with pre-determined network protocols. 

The processing unit 202 is able to control opera- 
tions of a user terminal by executing programs stored in 
memory device 204 or hard disk 206. Processing unit 

75 202 is also able to control the transmissions of pro- 
grams and data between memory device 204 and hard 
disk 206. 

Referring to Figure 3 f there is shown a hardware 
Uock diagram for a computer system 300, which is able 

so to support any of the web sites (112^, 112. 2 , .... 112 >N ), 
and comprises a processing unit 302, a memory device 
304, a disk drive interface 308.and a network communi- 
cation interface 334, all connected to a system bus 31 4. 
The disk drive interface 308 is coupled to a hard disc 

25 306. 

Memory device 304 the hard disk 306 are both able 
to store programs. However, memory device 304 has 
faster access speed than hard disk 306, while hard disk 
306 has higher capacity than memory device 304. 

30 Network communication interface 334 is able to 
provide an interface between computer 300 and data 
network 106 in compliance with pre-determined net- 
work protocols. 

Processing unit 302 is able to control operations of 

35 computer system 300 by executing programs stored in 
memory device 304 or hard disk 306, and is also able to 
control the transmissions of programs and data 
between memory device 304 and hard disk 306. 

In Figure 4, a user terminal includes five software 

40 function blocks 404 to 41 4. 

Browser software 404 is able to formulate and send 
requests to web sites, and to display the information 
retrieved from the web sites. Browser software is also 
able to receive user ID information requests from web 

45 sites. 

BrowserlD database 408 contains user information. 
BrowserlD client applet 406 is able to retrieve the 
user information from BrowserlD database 408 and 
passes it to browser software 404. However, BrowserlD 

so client applet 406 will not pass arty user information from 
BrowserlD database 408 without the explicit permis- 
sions the user set in the BrowserlD database 408 and 
comparing them to the def ined set of permissions in the 
BrowserlD website database 410 for that web site 414. 

55 If. in response to a request for user ID information from 
a web site, no permission is granted to the web site, the 
browser software 404 will alert the user to define a per- 
mission that will be entered into the BrowserlD website 
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database 410. BrowseriD client applet 406 is designed 
(programmed in Java for example) such that it can be 
executed (or interpreted) by any browser. 

BrowseriD website database 410 contains the 
names of web sites and the degree of identification 5 
information to be shared. 

Graphical User Interface 412 is able to provide an 
interface between a user and software function blocks, 
including BrowseriD client applet 406 and BrowseriD 
database 408. Through display monitor 210. keyboard 10 
225 and mouse 226, a user is able to initialize and 
update the BrowseriD database 408_and the 
BrowseriD website database 410, and to send control 
signals to Bro* /set ID cli Nit applet 406. 

Server software 4 1 4 is able to process the requests 15 
for information from browsers and return the information 
to the browser via HTTP, FTP, Gopher or other Internet 
information ira isfer protocols. 

When a u^er wants to visit web site 112, he/she can 
use keyboard 225 or mouse 226 to activate browser 20 
software 404 send a service request to the web site, 
as indicated by line 426. Upon receiving the service 
request, server software 414 for the web site sends a 
request for us^r ID information, as indicated by line 424 
which will invr'-e the execution on ihe user terminal of 25 
Browser ID Ci .nt Applrt 406. 

Figure 5 shows S owserlD information database 
408 which contains rovs of ID records, each with two 
fields, namely: a single ID Information Item followed by 
an information sharing Level Limit field. In the first 30 
record, the ID Information Item field contains a user's 
full name; -the Level Limit, field contains a numerical 
value, indicati:^ that the name will be revealed to a web 
server of a wh site if and only if the user chooses to 
provide that L-vel of u formation access for that web 35 
server. If so, V at sharr»g level will be indicated within 
the Browser! i: website database 410 by the Level Limit 
Field. Byway ' anothe example, in the seventh record, 
the ID Information lie i field contains social security 
number; the Level indi ^tor Field contains 7, indicating to 
that the social security number will only be transmitted 
to the web set vet of a web site if and only if the user 
specifies a web set er's access level within the 
BrowseriD website dat base 41 0 of value 7 or higher. 

In the enf xiimen! shown in Figure 5, it is assumed 45 
that the great. r the mrnerical value in the Level Limit 
field, the high- r is the -.ccess level. It can be designed 
the other way .round, < at is: the smaller of the numeri- 
cal value in th Level U titled, the higher is the access 
level. This me ns that record will be revealed to a web so 
server of a v ;b site f and only if the web server's 
access level f; rrs the f owserlD website database 410 
is smaller than or equai to Ihe Level Limit Field associ- 
ated to that rc - ord. 

As shown "n Figur-:- 5, BrowseriD website database ss 
410 is cornpr- 3d ol records with 2 fields. The first field 
is the public L ''*L for tl 2 sits. The second field contains 
the access Id :l assie .od to it by the user when infor- 



mation sharing level access was negotiated among the 
BrowseriD Client Applet and the web site server. This 
information is stored in the BrowseriD website database 
410 and is indexed by the BrowseriD database 408 
under control of the BrowseriD applet 406. 

Figure 7 illustrates the steps of disclosing user 
information to a web site. 

In step 704, a user sends a service request to one 
of the web sites (112. v 112. 2 , .... 112. N ). that requires 
access from one of the user terminals (102.-1, 102. 2 , .... 
1 02.m), to request an access to the web site. 

In step 706, server software 414 for the web site 
returns the web site name that will provide the service 
requested by the user and a request for information to 
BrowseriD Client applet 406. in Hs request, the server 
software (414) may specify the information items it 

needs, such as name, address, phone number etc. 

In step 707, BrowseriD Client applet 406 deter- 
mines whether an entry exists for the returned web ate 
name in the BrowseriD Website database 410. If an 
entry exists for the returned web site name, the opera- 
tion is led to step 710. If no entry exists for the returned 
web site name, the operation is led to step 708. 

In step 708, to negotiate a Level Limit to share infor- 
mation with the web site. BrowseriD Client applet 406 
presents an HTML form, including the information items 
specified by sever software 414, to the user. 

Following step 708. in step 709. BrowseriD Client 
Applet 406 creates an entry in BrowseriD database 408 
for the returned web site name, and the user selects a 
Level Limit, in reference to the HTML form. The user 
may choose to the Level Limit that complies with the 
information items specified by the web site, or choose to 
grant a lower Level Limit, The operation is then led to 
step 710. 

In step 710, BrowseriD Client applet 406 deter- 
mines whether any of the information items specified by 
the web site exceed the Level limit previously granted 
to the web site, by using the information stored in 
BrowseriD database 408 and BrowseriD website data- 
base 410. 

In step 710, if the Level Limit previously granted is 
not exceeded, the operation is led to step 712. II the 
Level Limit is exceeded, the operation is led to step 71 1 , 
in which BrowseriD Client applet 406 presents an HTML 
form to the user, asking the user to permit the increase 
in the Level Limit to the web site and asking if the user 
wants this to be a permanent update. After the user 
responds (either increases the Level Limit, or keeps the 
Level Limit previously granted unchanged), the opera- 
tion is then ted to step 712. 

In step 712. BrowseriD Client applet 406 responds 
to the server software with the information f ieids from 
BrowseriD database 408, according to the Level Limit 
granted to the web site. 

In step 722, server software 414 processes the 
requests from browser software 404, to proceed with 
web site activity. 
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Preferably, in the embodiment shown in figures 2 
and 4, the software function blocks for a user terminal 
are stored in memory device 204 or hard disk 206 and 
executed by processing unit 202. In the embodiment 
shown in figure 3, server soltware is stored in memory 
304 and executed by processing unit 302. 

It should be appreciated that the present invention 
provides a mechanism for users to control their own 
identification information. As such, the present invention 
requires that the Browser ID Client Applet which collects 
and delivers user information for web sites must be per- 
manently associated with the client's browser; an applet 
that is downloaded from a website server cannot be 
trusted to cooperate with the user s desire to control 
access to personal information. 

The present invention has the advantages in that: 

(a) a user can control ID information disclosure at 
differer t level; (b) it is convenient for a user to pro- 
vide the ID information; (c) it creates a mechanism 
to prov'de a standardized mechanism and format to 
provide ID information; and (d) web servers get 
complete and accurate ID information (if disclosed). 

Claims 

1. A method for providing information to a web site at 

a user ;erminai, characterized by the steps of: 

at the user terminal, 

(a) establishing a plurality of information 
records with respective access level indi- 
cators for indicating access levels; 

(b) receiving a request (706) from the web 
site with an access level being associated 
with the web site; 

(c) checking (707,710) the access level for 

the web site; and 

(d) retrieving (712) information records 
based on said access level indicators 
associated with the information records 
and the access level associated with the 

web z ' e. 

2. A method according to claim 1 , in which in step (a) 
the access Icel associated with the web site is 
defined by the user terminal. 

3. A method according to claim 1 or claim 2 further 
comprising er'^blLhing a plurality of first type of 
records contc Ting access levels associated w'rth 
the web sites md establishing a plurality of second 
type of recorc . each one of said second type of 
records conti Hng user information and access 
level associat I with said one record; 

ani on receiving a request from one of the web 



sites checking access level for the web site 
from said first type of records, and retrieving 
information from said second type of records 
based on the access level associated with the 
- web site and the access levels associated with 

said second type of records. 

4. An apparatus for providing information to a web site 
at a user terminal, characterized by the user termi- 
w rial comprising 

a receiver circuit for receiving a request from 
the web site with an access level being associ- 
ated with the web site; and 
75 a processor logic for checking the access level 

for the web site; and for retrieving information 
based on the access level associated with the 
web site. 

20 5. An apparatus according to claim 4 further compris- 
ing: 

a storage medium for storing a plurality of infor- 
mation records with respective access level 

25 indicators for indicating access levels, and 

arranged so that the processor logic retrieves 
information records based on said access level 
incficalors associated with the information 
records and the access level associated with 

30 the web site. 

6. A apparatus according to claim 5 in which said 
access level indicators are definable at the user ter- 
minal. 

35 
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